home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 875 < prev    next >
Text File  |  1994-08-27  |  6KB  |  123 lines
  1. Subject: Re: Gem List (fwd)
  2. Date: Tue, 19 Jul 1994 15:46:37 -0400 (EDT)
  3. From: Chris Herborth <herborth@53iss6.waterloo.ncr.com>
  4. In-Reply-To: <199407191600.AA01919@world.std.com> from "Lexicor@world.std.com" at Jul 19, 94 12:00:08 pm
  5. Message-Id:  <9407191808.gm15081@ncrhub1.NCR.COM>
  6. Precedence: bulk
  7.  
  8. What you wrote:
  9. > Wrong. Our library is much *smaller* than Gem++, yet has many more features.
  10. > The resulting executables that do the *same thing* as the equivalent Gem++
  11. > program are generally several times *smaller*, not to mention *faster*.
  12. > 
  13. > Go figure.
  14.  
  15. Go figure indeed.  C++ programs are larger than C programs because the
  16. _linkers_ being used were designed for C code.  Instead of being intelligent
  17. and linking in only the used members of a class (which is sort of what
  18. they do for C if your library is designed properly), it links in the whole
  19. class, which can be quite large.
  20.  
  21. C++ programs will remain large until OO linkers are developed.  People
  22. on _every_ platform complain about C++ programs being larger than C
  23. programs, and some use this as a "why C is better than C++" argument,
  24. which is silly, since it has nothing to do with either language, really.
  25.  
  26. How did you decide your GUIs were faster than GEM++'s GUIs, BTW?  In what
  27. respect?  Does it somehow manage to draw a window faster?  Do your scrollers
  28. scroll faster?  And what's the point if a programmer can use library A
  29. more effectively than library B?
  30.  
  31. > WinLIB PRO was designed after intensive study of over *20* GUI libraries.
  32. > It incorporates the best ideas of all of them (we steal from the best, and
  33. > forget the rest :-) WinLIB PRO is extremely powerful, yet extremely
  34. > easy to use. WinLIB PRO does most of the work for you, with an extremely
  35. > straightforward, simple API.
  36. > 
  37. > WinLIB PRO gives you the most amount of bang for the least amount of
  38. > effort (and code wise, WinLIB PRO is very, very efficient. Very very small
  39. > executables and very fast execution.)
  40.  
  41. I'll bet it won't make a GEM NetHack smaller than about 750k or so...  (Not
  42. a fair test, since plain NetHack compiles to *at*least* 700-800k; I think
  43. Warwick had to leave out several features in the GEM NetHack on
  44. atari.archive... it's binary is over 800k if I remember correctly.)
  45.  
  46. And when are you releasing the source code?
  47.  
  48. > Sozobon produces good object code? *laughs* I think your standing with most
  49. > of the people in this conference has dropped about 20 points from that
  50. > comment alone. Sozobon code is mediocre to fair, but far from 'good'.
  51.  
  52. Which is exactly what I'd call the Pure C optimiser...  GNU C's code may
  53. be large, but it's VERY good.  Personally, I have a hard drive, so I could
  54. care less if my binaries are a bit larger.
  55.  
  56. > I think that if people in this conference spoke more from EXPERIENCE and less
  57. > from OPINION, we would be much more productive.
  58.  
  59. In my EXPERIENCE and OPINION, assembly-language debugging is a cruel
  60. joke and a massive waste of time.  Some people swear by it though.  I
  61. prefer a souce-level debugger that speaks C or C++ to me...
  62.  
  63. > Very very few people I know are using MTOS. Most are disgusted with it like
  64. > I am. I know of *nobody* (except maybe you) who actually LIKES it. Even on a
  65. > Falcon030 it makes life miserable. On a TT it's barely tolerable.
  66.  
  67. On a Falcon, using a half-way reasonable graphics mode makes life
  68. miserable; forget multitasking.
  69.  
  70. > If you're talking about C++, you're right; it DRAGS EVERYTHING
  71. > in your library along with it whether it's used or not...
  72.  
  73. No it doesn't; the linker is stupid and drags everything in every _class_
  74. you use into your program.  This is wastefull and silly, but C++ is still
  75. a major win over C, IMHO.
  76.  
  77. > Consider the amount of people who use C++ over C on the atari, then re-think
  78. > the question about who will use the library.  I think you can answer that.
  79.  
  80. Oh, good!  Now we can go over why almost no-one (only the brave, the elite
  81. few!) uses C++ on the Atari again... whee.  It's a pointless point unless
  82. you plan to *sell* your library; then you need to decide if you should
  83. support the dozen or so people using Lattice, or the dozen or so people
  84. using Pure/Turbo C, or the dozen or so people using gcc.  Ok, maybe more
  85. than a dozen in each, but still, the numbers are not stunning in either
  86. of them.  If you support Pure/Turbo C, you get to compete with all those
  87. free GEM libs from Germany...
  88.  
  89. Something that just occured to me, folks...  WHY are we discussing various
  90. GEM libraries on the gem-list at this point?  I thought we were trying
  91. to hammer out some standards here...  I'm amazed at how argumentative this
  92. mailing list is (but then, I guess *all* Atari users need to blow off
  93. steam somehow these days).
  94.  
  95. > (I could go into a discussion on memory fragmentation from alloc'ing and
  96. >  free'ing memory for dynamically growing and shrinking a listbox, but I
  97. >  digress...)
  98.  
  99. Reasonable C support libraries should have malloc() and free() in them
  100. that keep track of larger chunks (usually 64k from what I've seen); that
  101. way, if you're going to malloc() a bunch of small things, and free() a
  102. few, then malloc() a few more, you're not fragmenting memory...  I'm
  103. presuming that you're playing devil's advocacte a little here, since nobody
  104. in their right mind would use the Malloc() GEMDOS call.
  105.  
  106. > I never claimed otherwise. I just pointed out that to change from a normal
  107. > slider to an active slider in Gem++ required a code change and recompilation
  108. > whereas in WinLIB PRO it simply requires a change to the slider's extended
  109. > object type in the resource editor.
  110.  
  111. The change for GEM++ would likely be changing one line of code; not a big
  112. deal if you're working on the application anyway.  The slider/active slide
  113. decision should be part of your design, not something you throw in for
  114. fun later.
  115.  
  116. Uh-oh, now we'll get into the consistant-user-interface argument again... :)
  117.  
  118. -- 
  119. ----------========================_   /\ ============================----------
  120. Chris Herborth                    \`o.0'       herborth@53iss6.Waterloo.NCR.COM
  121. Information Products Developer    =(___)=
  122. AT&T Global Information Solutions    U
  123.